Subject: Call for participation

From: "Chung-Huy Chen (254-4827 T/L 444)" <[email-masked]>
Date: Mon, 31 Jan 94 17:59:52 EST

ADC SIG,

  With the interest and great effort from Jeff Hildebrand at Boeing,
  the SIG has become active again.  In the following, four notes
  exchanged between Jeff and me are included.  The discussions were
  centered around two topics:
     i) data conversion and conversation-type values
    ii) how to retrieve a map name when a Receive call completes and
        takes the conversation into Reset state?

   I would like call your attention to the discussions and encourage
   you to contribute your ideas to the problems surrounding the
   automatic data conversion.

   Regards,
   Chung-Huy Chen

------ (1) --------------------------------------------------------------
Date: 12 January 1994, 09:29:52 EST
From: Chung-Huy Chen            254-4827  T/L 444    CHUNGHUY at RALVM6
To:   jhild at ct.si.cs.boeing.com
Subject: data conversion and conversation types

Jeff,

The CPI-C spec. has the following descriptions about conversation types:

   - Mapped conversations allow the programs to exchange arbitrary
     data records in data formats agreed by the application programmers.

   - Basic conversations allow program to exchange data in a
     standardized format.
     (This standardized format refers to a logical record.)

When using a basic conversation, the program has to pack the data as
a sequence of logical records.  If any difference in data encodings
used by the two systems exists, the program has to do the conversion
itself.  In this case, data conversion, if needed, is above the CPI-C
interface.

In case of a mapped conversation, the formats of data exchanged
between two programs have been agreed to by the programs and known by
the underlying CRM.  The CRM can then perform any manipulation on the
data for the program.  I think data conversion falls into this type
of conversation well.  "Mapped conversation" does not just mean the CRM
packs the data in the LL format, although the statement is true today
and is just for the LU.

I think there is no need for a third conversation type value "data
conversion" as you suggested.  Data conversion is part of the mapped
conversation.

I'll be in the building but not in my office this afternoon.  If you
would like to discuss this subject further, please send me a note or
I'll be in my office tomorrow (Thursday).

Regards,  Chen
------ (2) --------------------------------------------------------------
From: "Hildebrand, Jeff" <[email-masked]>
To: "Chung-Huy Chen (254-4827 T/L 444)" <[email-masked]>
Subject: RE: data conversion and conversation types
Date: Wed, 12 Jan 94 12:45:00 PST
Return-Receipt-To: <[email-masked]>
Encoding: 138 TEXT

 ----------
From: Chung-Huy Chen (254-4827 T/L 444)
To: jhild
Subject: data conversion and conversation types
Date: Wednesday, January 12, 1994 9:29AM

Chen,
I understand your note, and thanks for taking the time to think about the
topic.

Ideally, data conversion is simply another form of Mapped conversation.
The current form of mapping essentially is a buffering mechanism and could
be identified with a 'canned' name of standard or even blank.  This would
allow the current mechanism to continued to be used and not affect current
programs, LU 6.2 would still use the buffering method and OSI TP would use a
vendor
supplied version of the UDT U-ASE ( Unstructured Data Transfer User ASE) to
do the same buffering over OSI.  Real data conversion requires real map
names.

The bind is retreiving the map name after a receive deallocate.  The state
table for the Receive ( I or W) transitions to the Reset state immediately
upon receipt of
the Deallocate (dn).  There is a need to have enough of the conversation
hang around until the
EXTRACT-MAP-NAME  service can be called.  There seems to be two ways of
doing this, (though I
am probably overlooking  other solutions):

1.  Makeup a rule that the map name must hang around for a while - like
    secondary info codes.  As you said this is a problematic solution
    at best.

2. The second solution is to change the state tables.  This could be done
    several ways, but the three simplest are:
    Note: dn = DEALLOCATE NORMAL, nd = NO DATA

     A.  Use Conversation-Type characteristic MAPPED and embody that as M.
           Under both types  of receives the sate table would look like -

                 (^M) [dn]       1   go to reset (deallocate for basic
                                     conversation)
                 (M)   [dn]      -   (stay in receive state, deliver
                                     data, and  deliver OK as return code)
                 (M)   [nd dn]   1   go to reset ( the second receive has no
                                     data associated with it, deliver dn
                                     as return code)

         The problem with this approach is that it forces existing programs
         to make an extra receive.  At the least the reaction will be to
         sight
         it as inefficient to existing programs, and at worst it could break
         programs that expect to receive a deallocate without an intervening
         receive.  If these two problems were eliminated, they could be only
         theoretical fears,  this solution  would work well.

    B. The second solution is to duplicate method A but have the state table
       check the map name to see  if it is the default one ie., STANDARD
       or BLANK that signifies the current method is in use.  Because
       the RESET has not yet happened the API could still interrogate the
       map name. The state table would look like:

               (^M or M   MAP-NAME = STANDARD)   [dn]   1     go to
                                    reset (deallocate for basic or
                                    traditional mapped conversation)
               (M   MAP_NAME ^ STANDARD)         [dn]   -
                                    (stay in receive state, deliver data,
                                    and deliver OK as return code)
               (M)                            [nd dn]   1
                                    go to reset ( the second receive has no
                                    data associated with it, deliver dn as
                                    return code)

    C. The third solution is to make a new value for the Conversation- Type
       Characteristic called Data Conversion (DC) its state table
       would look like:
               (^DC)  [dn]      1    go to reset (deallocate for basic or
                                     traditional mapped conversation
               (DC)   [dn]      -    (stay in receive state, deliver
                                     data, and deliver OK as
                                     return code)
               (DC)   [nd dn]   1    go to reset ( the second receive has
                                     no data associated with it,
                                     deliver dn as return code)

    What do you think?
Thanks,
Jeff

------ (3) & (4) --------------------------------------------------------
From: "Hildebrand, Jeff" <[email-masked]>
To: "Chung-Huy Chen (254-4827 T/L 444)" <[email-masked]>
Subject: Re: data conversion and conversation types
Date: Mon, 31 Jan 94 10:15:00 PST
Return-Receipt-To: <[email-masked]>
Encoding: 118 TEXT

 ----------
From: Chung-Huy Chen (254-4827 T/L 444)
To: jhild
Subject: Re: data conversion and conversation types
Date: Friday, January 14, 1994 4:25PM

>Chen,

Jeff,

I don't seem to be able to find any support in the CPI-C spec about
the statement that "the current form of mapping essentially is
a buffering mechanism."  Here is what I can derive from the spec:

From user's perspective,

                            Program itself
                         +-----------------> Basic conversation
   who prepares data? ---:
                         +-----------------> Mapped conversation
                                 LU

Furthermore, for a basic conversation,

                                          Logical records
                                        +-----------------> fill = LL
   how does the program handle data? ---:
                                        +-----------------> fill = buffer
                                               buffer

For a mapped conversation,
 - the LU will always prepare data in the form of logical records
   for the program
>
> The LU does this by chopping up the user data record into
> pieces that the underlying CRM (LU 6.2) can handle.  I called it
> a buffering  mechanism because it is a pretty good
> description of what it does, though other adjatives could be used.
>

 - the program is not aware of logical records or any processing
       which might be done by the LU.  (In my opinion, a candidate for
       additional LU processing is data conversion, and it is
       transparent to the program just as logical records.
       Therefore, no migration problem exists.)

Now to take into considerations of conversations using an OSI TP CRM,
  - a basic conversation carries data in UDT
  - what does a mapped conversation do?  (I'd say data conversion.)

It is possible to define a third conversation-type value called data
conversion.  But what do we gain from this?
Moreover, introducing a third conversation-type value will have to first
answer questions such as:
  - What is the meaning for a program to Set the conversation type
    to this new value before Allocate is issued?
    (In LU, a byte in the ATTACH reflecting either conversation type
     flows.  How will the LU treat this new value?)
  - Why must the program know the difference between a mapped conversation
    and data conversion?

My belief is that data conversion fits into the mapped conversation
type well.

>
>
>I agree whole heartily with you.  The question is how to do this.
>

                          * * *
The second problem is how to retrieve a map name when a Receive call
completes and enters Reset state?

I see an alternative solution which requires no additional state
and is free of migration concerns.

 - When the CRM receives data with no map name, the Receive works
   the same as today.

 - When the CRM receives data with a map name, the Receive behaves
   as follows:
      If a deallocation indication has also been received,
      the Receive returns return_code=CM_OK (as opposed to
      CM_DEALLOCATE_NORMAL when no map name) and remains in the
      Receive state (as opposed to entering the Reset state when
      no map name) at the same time it returns data_received=
      CM_COMPLETE_DATA_RECEIVED.
>
> BIG QUESTION??  How can this be done without impacting the
> state tables.   If it can be, then this is the solution.
>

   The program then issues Extract_Map_Name to obtain a map name.
   When the program subsequently issues a Receive call, the call
   returns CM_DEALLOCATE_NORMAL.

                         * * *
I have seen some important discussions going on between us.  I think
these discussions are also important to other SIG members who can
benefit from or even contribute to the discussions.  I also think,
with the awareness of the whole SIG, we can make better, easier, and
faster progress on this architecture.  What do you think?

>
>We should probbably release all the notes as one long note?
>
> Thanks jeff

If you agree, I'll package the previous notes and distribute them
to the SIG and start discussions among the SIG members.

Regards,  Chen